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(57) Abstract 

A computer implemented method and a computer program for synchronizing a first (13) and a second database (14), where data is 
provided for keeping track of whether the records of the first database have been added or changed since a previous synchronization. Based 
on the data reflecting whether the records of the first database have.been added or changed since a previous synchronization, it is determined 
whether the records of the first database have been changed or added since the previous synchronization. The representative record is stored 
in a history file (19) which contains records reflecting the contents of records of the databases at the time of a previous synchronization. 
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SYNCHRONIZATION OF DATABASES 
Background 
This invention relates to synchronizing 
5 incompatible databases. 

Databases are collections of data entries which 
are organized, stored, and manipulated in a manner 
specified by applications known as database managers 
(hereinafter also referred to as "Applications"; 

10 hereinafter, the term "database" also refers to a 

database manager combined with a database proper) . The 
manner in which database entries are organized in a 
database is known as the data structure of a database. 
There are generally two types of database managers. 

15 First are general purpose database managers in which the 
user determines (usually at the outset, but subject to 
future revisions) what the data structure is. These 
Applications often have their own programming language 
and provide great flexibility to the user. Second are 

20 special purpose database managers that are specifically 
designed to create and manage a database having a preset 
data structure. Examples of these special purpose 
database managers are various scheduling, diary, and 
contact manager Applications for desktop and handheld 

25 computers. Database managers organize the information in 
a database into records, with each record made up of 
fields. Fields and records of a database may have many 
different characteristics depending on the database 
manager's purpose and utility. 

30 Databases can be said to be incompatible with one 

another when the data structure of one is not the same as 
the data structure of another, even though some of the 
content of the records is substantially the same. For 
example, one database may store names and addresses in 

35 the following fields: FIRST_NAME, LAST_NAME, and 
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Applications to speed up the synchronization process. 
Some Applications provide information for keeping track 
of which records were changed, deleted, or added since 
the last synchronization. The invention uses these 
5 features to speed up the synchronization process by 

retrieving only those records which have been changed or 
addfed since a previous synchronization. 

The invention provides a computer implemented 
method and a computer program for synchronizing a first 

10 and a second database. Based on data reflecting whether 
the records of the first database have been added or 
changed since a previous synchronization , it is 
determined whether the records of the first database have 
been changed or added since the previous synchronization. 

15 If one of the records of the first database has not been 
changed or added since the previous synchronization, a 
synchronization with records of the second database is 
performed using a record representative of the one record 
at the time of a previous synchronization. The 

20 representative record is stored in a history file which 
contains records reflecting the contents of records of 
the databases at the time of a previous synchronization. 

Preferred embodiments of this aspect of the 
invention may include one or more of the following 

25 features. The data provided for keeping track of 

whether the records of the first database have been added 
or changed since a previous synchronization may be 
database generated data, stored in the records of the 
first database. 

30 The computer generated data indicates the most 

recent date and time of when a record was created or 
changed. The computer generated data includes a flag set 
when a record is created or changed. 

The first database provides further database 

35 generated data indicating which records were deleted 
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database located on a first computer and a 'second 
database located on a second computer. At the first 
computer, it is determined whether a record of the first 
database has been changed or added since a previous 
5 synchronization, using a first history file located on 
the first computer comprising records representative of 
records of the first database at the completion of the 
previous synchronization. If the record of the first 
database has not been changed or added since the previous 
10 : synchronization, the first computer sends the second 
computer information which the second computer uses to 
identify the record of the first database to be 
unchanged. 

The embodiments of this aspect of the invention 

15 may include one or more of the following features. 

A second history file may be located on the second 
computer. The second history file contains records 
representative of records of the first database at the 
completion of the previous synchronization, where one of 

20 the representative records represents the record of the 
first database determined to be unchanged. Then, at the 
second computer, a synchronization of the second and 
first databases is performed using the one of the 
representative records. 

25 The information sent from the first computer to 

the second computer can be used to locate the one of the 
representative records in the second history file. The 
second history file can store information in relation to 
the representative records and the one of the 

30 representative records in the second history file can be 
identified from that stored information. Additionally, 
the information sent from the first computer to the 
second computer can include information that matches the 
information stored in relation to the one of the 

35 representative records in the second history files. 
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computers , the time needed to synchronize the two 
databases is decreased 

Also, when transmitting data from one computer to 
another, using a content based code, that requires less 
5 bandwidth for being transmitted and nonetheless 

identifies a record, results in a slow data transfer 
links being used more efficiently. 

The invention may be implemented in hardware or 
software, or a combination of both. Preferably, the 

10 technique is implemented in computer programs executing 
on programmable computers that each include a processor, 
a storage medium readable by the processor (including 
volatile and non-volatile memory and/ or storage 
elements) , at least one input device, and at least one 

15 output device. Program code is applied to data entered 
using the input device to perform the functions described 
above and to generate output information. The output 
information is applied to one or more output devices. 

Each program is preferably implemented in a high 

20 level procedural or object oriented programming language 
to communicate with a computer system. However, the 
programs can be implemented in assembly or machine 
language, if desired. In any case, the language may be a 
compiled or interpreted language. 

25 Each such computer program is preferably stored on 

a storage medium or device (e.g., ROM or magnetic 
diskette) that is readable by a general or special 
purpose programmable computer for configuring and 
operating the computer when the storage medium or device 

30 is read by the computer to perform the procedures 
described in this document. The system may also be 
considered to be implemented as a computer-readable 
storage medium, configured with a computer program, where 
the storage medium so configured causes a computer to 

35 operate in a specific and predefined manner. 
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Figure 13 is pseudocode for a host segment of a 
synchronization program when loading records from and 
unloading records to the remote database, when the 
database assigns unique IDs. 
5 Figure 14 is pseudocode for a remote segment of a 

synchronization program when loading records from and 
unloading records to the remote database, when the 
database does not assign unique IDs. 

Figure 15 is pseudocode for a host segment of a 
10 synchronization program when loading records from and 
unloading records to the remote database, when the 
database assigns unique Ids. 

Description 

Briefly, a synchronization program 100 (Fig. 1) 
15 running on a computer loads records of two databases, 
e.g. a scheduling database on the computer and another 
one on a remote handheld or notebook computer. The 
synchronization program then synchronizes the records of 
those databases using a history file that contains 
20 records representative of the records of the two 

databases at the end of a previous synchronization. The 
synchronization program uses the history file to 
determine, for example, which records have been changed, 
added or deleted since the previous synchronization and 
25 which records of the two databases correspond to one 
another • 

If one of the databases has the capability to 
provide database generated information or data which can 
be used to determine, for example, whether a record has 
30 been changed, added, or deleted since a previous 

synchronization, the synchronization program uses that 
information to determine whether a record has been 
changed, added, or deleted. Of course, that database 
generated information is less than the whole record of 
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previous synchronization. Using the history file to 
reconstruct the record instead of loading the record can 
result in significant saving of time - where for example 
the data transfer link between the two computers is slow 
5 - since typically a majority of records in databases are 
unchanged records. The synchronization program thereby 
increases the efficiency of performing synchronization- 
between two databases • 

In order to better understand embodiments the 

10 invention described herein, we will briefly describe the 
overall structure of a synchronization program and the 
method it uses to synchronize databases, both of which 
are described in more detail in the following commonly 
owned U.S. patent applications, incorporated in their 

15 entirety by reference, "Synchronization of Recurring 
Records in Incompatible Databases 11 , Serial no. 
08/752,490, filed on November 13, 1996 (hereinafter, 
"application '490"); "Synchronization of Databases with 
Record Sanitizing and Intelligent Comparison," Serial no. 

20 08/749,926, filed November 13, 1996 (hereinafter, 

"application / 926"); "Synchronization of Databases with 
Date Range," Serial no. 08/748,645, filed November 13, 
1996 (hereinafter, "application '645"). We will then 
describe specifically how the synchronization program 

25 operates when at least one of the databases provides 
information indicating that records have been changed, 
added or deleted since a previous synchronization. 

Fig. 1 shows the relationship between the various 
modules of an embodiment of synchronization program 100. 

30 Translation Engine 1 comprises Control Nodule 2 and 
Parameters Table Generator 3. Control Module 2 is 
responsible for controlling the synchronizing process by 
instructing various modules to perform specific tasks on 
the records of the two databases being synchronized. 

35 (Fig. 3 shows the steps taken by this module.) The 
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designating a priority for a "to do" item should be 
limited to 1, 2, or 3. Sanitizing a record is to change 
the content of the fields of a record of one database to 
conform to the rules of data value of another database. 
5 Rules of data value and sanitization are described in 
detail in the '490, '926 and '645 applications. 

In the described embodiment, the modules of 
A_Translator 5 are designed specifically for interacting 
with A_database 13 and A_Application 17. Their design is 

10 specifically based on the record and field structures and 
the rules of data value imposed on them by the 
A_Application, the Application Program Interface (API) 
requirements and limitations of A_Application 17 and 
other characteristics of AJDatabase and A_Application. 

15 The same is true of the modules of B_Translator 9. These 
Translators are not able to interact with any other 
databases or Applications. They are only aware of the 
characteristics of the database and the Application for 
which they have been designed. Therefore, in the 

20 preferred embodiment, when the user chooses two 

Applications for synchronization, the Translation Engine 
chooses the two Translators which are able to interact 
with those Applications. In an alternate embodiment, the 
translators can be designed as table-driven codes, where 

25 a general Translator is able to interact with a variety 
of Applications and databases based on supplied 
parameters . 

Fig. 3 is the pseudocode for the described 
embodiment of Control Module 2 of the Translation Engine 

30 1. We will use this pseudocode to generally describe the 
steps taken when synchronizing two databases performed by 
the synchronization program 100. Control Module 2 first 
instructs the Parameter Table Generator 3 of Translation 
Engine 1 to create Parameter_Table 4 (Step 100) . In step 

35 102, the Translation Engine instructs synchronizer 15 to 
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module 7 of the A_Translator 5, synchronizer 15 maps that 
record using an A->B_Map before writing the record into 
the next available spot in the Workspace* Since the 
A_records are mapped into the B_Record format, when the 
5 B_Sanitizer is instructed by Control Module 2 to begin 
sanitizing those records and starts asking for them from 
synchronizer 15 , they already have the &_Database format. 
Therefore, synchronizer 15 does not need to map them 
before sending them to the B_Sanitizer module 12 of the 

10 B_Translator 19. For the same reason, there is no need 
for them to be mapped once they are sent back by the 
BjSanitizer after having been sanitized. However, in the 
case of B_records, they must be mapped using a B-+A map 
prior to being sent to A_sanitizer and then mapped back 

15 using an A-*B map. At this point, all records are loaded 
into the Workspace. 

Synchronizer 15 then performs a Conflict Analysis 
and Resolution ("CAAR") procedure on the records in the 
Workspace, which procedure is described in detail in the 

20 '490, '926 and '645 applications. Briefly, during this 
process, synchronizer 15 compares the records in the 
workspace and determines what synchronization actions 
should be taken. Synchronizer 15 processes the records, 
including comparing them to one another, in order to form 

25 them into groups of related records called corresponding 
item groups (CIGs) . Each CIG may comprise at most one 
recurring or a group of related nonrecurring records from 
each of the databases and the history file. After 
forming CIGs from all records of the two databases, 

30 synchronizer 15 compares the records in each CIG with one 
another, determines their differences, and decides what 
synchronization action should be taken. Synchronization 
actions with respect to a record include updating, 
deleting, adding, or not modifying that record. For 

35 example, if after comparing the records in a CIG, 
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instructs the A_Translator to unload the A_Records from 
the Workspace (step 111) . This unloading is done in the 
same way as it was done by the B_Translator. Control 
Module 2 next instructs synchronizer 15 to create a new 
5 history file (step 112) During unloading, the Unloader 
module of the A_Translator uses the A-+B map the map the 
records in the Workspace into the format of A_database 
records . 

At this point Synchronization is complete. 

10 : The speed of the above synchronization process can 

be improved in the case of databases which provide data 
for keeping track of which records have been changed, 
added, deleted, or left unchanged since a previous 
synchronization. As previously described, there are 

15 generally two types of such databases: "medium 

synchronization" and "fast synchronization" databases. 

A "fast synchronization" database is a database 
which provides information regarding changes, deletions, 
and additions to its records from one synchronization to 

20 the next. Synchronization program 100 can use this 
information to speed up the synchronization process 
because records which have not been changed are not 
loaded from the database. Since the majority of records 
loaded by regular Translators are typically unchanged 

25 records, far fewer records are loaded from the database 
into Workspace than would otherwise be the case. 

Certain features are required for a database to be 
a fast synchronization database. The database assigns 
each record of the database a unique ID and provides a 

30 mechanism for keeping track of which records are added, 
changed, or deleted from synchronization to 
synchronization, including a list of deleted records. 

There are at least two ways to keep track of 
additions, changes, and deletions in a database. 
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fast synchronization translator provides deleted records, 
which the regular Translators does not. 

In order for such databases to be synchronized 
without resorting to treating them as regular databases 
5 (necessitating loading all records) , synchronizer 15 

transforms fast synchronization database records from the 
Translator into equivalent regular database records. 
These transformed records are then used by synchronizer 
15 in the synchronization process. There are two 

10 transformations which are necessary. First, synchronizer 
15 needs to transform deleted records received from the 
fast synchronization Translator into a regular database 
deletions. Second, synchronizer 15 needs to transform 
lack of output by the fast synchronization Translator 

15 into unchanged records. 

Synchronization program 100 performs these 
transformations by using the history file. When the 
databases are synchronized for the first time, all , 
records in the fast synchronization database are loaded 

20 into the history file. As changes, additions, and 

deletions are made to the fast synchronization database, 
during each of the subsequent synchronization, the same 
changes, additions, and deletions are made to the history 
file. ^Therefore, the history file at the end of each 

25 subsequent synchronization contains a copy of the data in 
the fast synchronization database. 

When a fast synchronization database Translator 
supplies no input for a unique ID history file record, 
synchronizer 15 finds (i.e. identifies) the corresponding 

30 history file record in Workspace 16, copies it into 

Workspace 16, and treats the copied record as if it were 
loaded by the fast synchronization translator itself. 

Referring to Fig. 4, steps 1050-1051, synchronizer 
15 first verifies that there is an appropriate history 

35 file. Because synchronization of fast synchronization 
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the '490, ' 926, and '645 applications, is performed on 
the records. In general terms, during orientation 
analysis, deletions and changes to fast synchronization 
database records are joined with their history file 
5 counterparts in unique ID bearing CIGs (step 1107) . 
These are CIGs in which at least one of the records is 
assigned a unique ID, Synchronizer 15 may treat these 
CIGs differently than other CIGs to improve the 
efficiency of the synchronization program, for example, 

10 by matching them to history file records based on their 
unique ID value instead of the content of record, as 
described in detail in applications '490, '926, and f 645. 

All history file records and their CIGs are now 
examined. If there is no corresponding record from the 

15 fast synchronization database, it means that the record 
was unchanged. A clone of the record is made, labelled 
as being from a fast synchronization database, and joined 
to the history file record's CIG. At this point the 
deleted fast synchronization database records marked as 

20 deleted are removed from CIGs (step 1109) . The fast 
synchronization records marked as changed are joined in 
doubleton CIGs (i.e. CIGs entry records from two 
databases) . Those marked as additions are singletons. 
At this point, the synchronization can proceed as if 

25 record of a unique ID bearing regular database were just 
loaded into Workspace 16. 

Whenever records are loaded from a fast 
synchronization database, all records are loaded so that 
at the end of synchronization the history file will be 

30 the same as the fast synchronization database. 

Therefore, referring to Fig. 5, in order to perform date 
range limited synchronization, synchronizer 15 marks the 
records which fall outside the current and the previous 
date ranges. A record marked as an added, or during 

35 synchronizing from scratch, a record that falls outside 
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fast synchronization Translator waits for an 
acknowledgement from synchronizer 15 that the record has 
been accepted. 

In the case no such acknowledgement is received 
5 for a record, the Translator needs to be able to provide 
that record again to synchronizer 15. If the database 
allows resetting individual Dirty bits, the Translator 
merely does not set that bit. If not, the Translator 
keeps a separate file in which it keeps a record of which 

10 : fast synchronization records were not accepted. The file 
may contain the unique IDs of those records. The 
Translator then uses that file to provide synchronizer 15 
with those records during the next synchronization. 

We will now describe synchronization in the case 

15 of medium synchronization databases. Medium 

synchronization databases have more limited capabilities 
than fast synchronization databases for keeping track of 
addition, deletions, or changes. Medium synchronization 
database do not keep track of deletions. They however 

20 still have the capability to provide information 

regarding what records were added or modified since a 
previous synchronization. This information typically 
takes the form of date and time stamps stored with the 
record or a Dirty bit, as previously described. 

25 In the case of medium synchronization databases, 

the Translator provides synchronizer 15 with information 
indicating which records have been added/changed and 
which records are unchanged. Based on this information 
and the history file, synchronizer 15 determines which 

30 records were deleted. Synchronizer 15 assumes that those 
records in the history file for which no matching unique 
ID was obtained from the database are deleted records and 
flags them as such. In identifying a record as having 
been deleted from the database, synchronizer 15 can 

35 easily determine what synchronization action should be 
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replicates the data of the unchanged record using the 
content of the history file, in the same manner as in the 
case of fast synchronization databases. By relevant, we 
mean data in the fields that are synchronized. 
5 If a record is not unchanged, then the record has 

either been modified and added since the previous 
synchronization. The translator sets value of the hidden 
field as 'C which indicates to synchronizer 15 that the 
record was either added or changed (step 1206) . The 
10 translator then loads the changed or added record, from 
the database, field by field (steps 1207-1209) . The 
translator then loads the record into the workspace (step 
1211) . 

After the translator has loaded all the records in 

15 the database, there are in essence two logical lists in 
workspace 16. One is the list of records identified as 
changed/added since a previous synchronization. Second 
is the list of records identified as unchanged since a 
previous synchronization. Synchronizer 15 compares the 

20 unique IDs of the records in these two lists with the 

unique IDs in the history file (step 1213) . (In the case 
of date range limited synchronization, the whole database 
would be loaded but only those records which are in the 
date range will be synchronized, as was the case for fast 

25 synchronization databases.) Based on the comparison, 
synchronizer 15 determines which records in the history 
file are no longer present in the database. Synchronizer 
15 determines that these records have been deleted and 
sets the hidden field value for these records as 'D' 

30 (step 1214). Synchronizer 15 processes these records in 
the same manner as when synchronizer 15 receives an 
indication from a fast synchronization database that a 
records has been deleted. The synchronizer also compares 
the unique IDs changed records to the unique IDs of the 

35 records of the history file (step 1215). The 
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database for records that have date and time stamps that 
are subsequent to the date and time stamp of the last 
synchronization. Translator determines these records to 
be changed or added since the last synchronization. The 
5 rest of the processing by the Translator and synchronizer 
are the same as the embodiment described in reference to 
Fig. 6. 

In the case of those databases that provide Dirty 
bits instead of date and time stamps, the Translator 

10 determines which records have their Dirty bits set. 

Those that have their Dirty bit set are changed or added 
records while those that do not have their Dirty bits set 
are unchanged records. The rest of the processing by the 
Translator and synchronizer are the same as the 

15 embodiment described in reference to Fig. 6. 

Fig. 8 shows another embodiment for synchronizing 
a medium synchronization database. In this case, for 
each record (step 1350) , the translator loads the unique 
ID and the date and time stamp or Dirty bit, as may be 

20 the case. If the record has not been modified or added 
since the previous synchronization (step 1353), the 
translator calls a special function (PutUnchangedRecord) 
of synchronizer 15 and also supplies the unique ID of the 
unchanged record to the synchronizer (step 1354). In 

25 response to the function call, synchronizer 15 searches 
the history file for the supplied unique ID (step 1355) 
and clones the matching history file record (step 1356) . 

If the record has been modified or added since the 
previous synchronization (step 1357), the record is 

30 loaded from the database (step 1358-1360) and loaded into 
the workspace (step 1361) . Synchronization then proceeds 
as if the records of a regular database (i.e. a database 
that does not provide information that may be used to 
keep track of whether records of the database have been 

35 changed, added or deleted) are loaded, as described 
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programs other than a database, as in the case of, for 
example, general purpose computers such as desktop and 
notebook computers, or handheld computers having 
sufficient memory and processing power. In such a case, 
5 the synchronization program may be distributed between 
the two computers so as to, for example, increase the 
efficiency of using of a slow data transfer link between 
the two machines* 

Briefly, at remote computer 22, remote segment 26 

10 of the synchronization program loads records of remote 
database 13. Remote segment 26 then determines which 
records of the remote database have been changed/ added, 
deleted or left unchanged since a previous 
synchronization. If the remote database assigns unique 

15 identification codes (i.e. unique ID) to its records, 
remote segment 26 can further differentiate between 
records than have been added and those than have been 
changed since the previous synchronization. Remote 
segment 26 uses a remote history file 30 which stores 

20 data representing or reflecting the records of the 
database at the completion of the previous 
synchronization. This data may be a copy of remote 
database 13. It may also be hash numbers for each of the 
records of the remote database. If the remote database 

25 assigns unique IDs, the remote history file may contain 
those unique IDs together with the hash numbers of the 
records corresponding to the stored unique IDs. 

Remote segment 26 sends those records of the 
remote database that have been changed or added to the 

30 host segment or the host computer. However, the remote 
segment does not send the unchanged or deleted records to 
the host computer. Instead, the remote segment sends a 
flag indicating the status of the record (e.g. unchanged 
or changed) and some data or information that uniquely 

35 identifies the record to the host segment. This data or 
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components of the synchronization program, -such as the 
name of the databases being synchronized and user 
preferences. Fig. 11 is the pseudocode of the steps 
taken by this module. The Synchronizer 15 has primary 
5 responsibility for carrying out the core synchronizing 
functions. It is a table-driven code which is capable of 
synchronizing various types of databases whose 
characteristics are provided by control module 2. The 
Synchronizer creates and uses a host workspace 16 (shown 

10. in detail in Fig. 2) , which is a temporary data array 
used during the synchronization process. 

A host translators includes two modules: a 
reader module 10 which reads the data from the host 
database 14 and an unloader module 10 which analyzes and 

15 unloads records from the host workspace into the host 
database 14. Remote segment 26 also has similar modules 
for reading and unloading data from the remote database. 
The remote segment is designed specifically for 
interacting with remote database 13. The design of the 

20 remote segment is specifically based on the record and 
field structure of the remote database and remote 
database's Application Program Interface (API) 
requirements and limitations and other characteristics of 
the remote database. Similarly host translator 9 is 

25 designed specifically for the host database. The remote 
segment and host translator are not able to interact with 
any other databases or Applications. They are only aware 
of the characteristics of the databases for which they 
have been designed. In an alternate embodiment, the host 

30 translator and the remote segment can be designed as a 
table-driven code, where a general Translator is able to 
interact with a variety of databases based on the 
parameters supplied by, for example, the Control Module 
2 . It should be noted that the remote segment and host 
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operation of the control module as if a history file 
exists and will be used. 

Once the History File is loaded into the host 
workspace, Control Module 2 instructs host translator 13 
5 to load the host database records (step 403) . Host 
Reader module 11 of the host Translator reads the host 
database records and sends them to the Synchronizer for 
writing into the host workspace. 

Control Module 2 then instructs remote segment to 

10 send the records of the remote database (step 404) . 

Remote segment 26 reads the remote database records and 
sends them to Synchronizer 15 for writing into the host 
workspace. The actions taken by the synchronizer and 
the remote segment in response to step 404 will be 

15 described in detail in reference to Figs. 12-15, below. 

Records in the host workspace are stored according 
to either the host database or the remote database data 
structures. Therefore, as synchronizer 15 receives each 
record, the Synchronizer maps that record using the 

20 appropriate record map (i.e. either a remote database to 
host database record map or a host database to remote 
database record map) before writing the record into the 
next available spot in the host workspace. Mapping may 
be performed by other modules, e.g. the remote segment. 

25 The records may also be "translated", i.e. cast into a 
format which synchronizer can use (a "translation" method 
is described in the '390 patent). For example, a date 
stored as "April 1, 97" may be translated into a format 
preferred by the synchronizer, e.g. "4-1-97". 

30 Control module 2 then instructs the Synchronizer 

to perform a Conflict Analysis and Resolution ("CAAR") 
procedure on the records in the host workspace (step 
405) , which procedure is described in detail in the 
following applications of the assignee hereof, Puma 

35 Technology, Inc. of St. Jose, California, incorporated by 
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record with the other database. We will describe below 
in detail the steps performed by the synchronizer and the 
remote segment in response to the output of CAAR as the 
output relates to the remote database. 
5 Once Synchronizer 15 finishes performing CAAR on 

the records, the records may be unloaded or written into 
their respective databases, including any additions, 
updates, or deletions. However, prior to doing so, the 
user is asked to confirm proceeding with unloading (steps 

10 108-109) . Up to this point, neither the databases nor 
the History File have been modified. The user may obtain 
through the Control Module's Graphical User Interface 
(GUI) various information regarding what will transpire 
upon unloading. 

15 If the user chooses to proceed with 

synchronization and to unload, the records are then 
unloaded in order into the host database, the remote 
database and the History File. The Synchronizer in 
conjunction with the host translator and the remote 

20 segment perform the unloading for the databases. 

Synchronizer 15 creates a host history File and unloads 
the records into it. Control Module 2 first instructs 
the host translator to unload the records from host 
workspace into the host database. Following unloading of 

25 the host records, Control Module 2 instructs the 

synchronizer and the remote segment to unload the remote 
records from the host workspace (step 409). We will 
describe in detail below, in reference to Figs. 12-15, 
the specific actions taken by Synchronizer 15 and remote 

30 segment 26 in order to unload data from the host 

workspace into the remote database and the update remote 
history file 28. Control Module 2 next instructs the 
Synchronizer to create a new History File (step 112) . At 
this point Synchronization is complete. 
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implemented with any synchronization program that is able 
to synchronize such databases. 

Generally, the remote segment sends the host 
segment, over the data transfer link, only the content of 
5 those records that have been changed or newly added. As 
for unchanged records, the history file contains all 
necessary information to recreate or synchronize those 
records, if needed. Therefore, it is not necessary to 
transfer those records to the host segment. Only some 
10 data or identification code that uniquely identifies the 
record to the Synchronizer need be transferred for such a 
record. Since the majority of records are typically 
unchanged records, not transferring them over the slow 
data transfer link improves the efficiency of the 
15 synchronization process. 

After all necessary information has been 
transferred to the host segment, the Synchronizer 
synchronizes the databases. Following synchronization, 
the host segment transfers information necessary to 
20 update the remote database and the remote history file to 
the remote segment. The remote segment then updates its 
history file and the remote database. 

Since both the host and remote segments rely 
heavily on history files to enable distributed 
25 synchronization, it is important that the host and remote 
segments use history files that correspond to one 
another, i.e. both contain records corresponding to a 
previous synchronization of the same two databases. In 
the described embodiment, the remote and host history 
30 files are named using a common naming convention. The 
name of a file is made up of six components: 

1) Name or ID of the host computer, which may be 
an assigned name such as an assigned GUID in the case of 
operating systems by Microsoft Corporation of Redmond, 
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the remote segment finds a remote history file that 
matches the host history file (i.e. a remote history file 
that matches the host history file) (step 502) , then the 
remote segment examine the date and time stamp of the 
5 host and remote history files. If the date and time 
stamp in the remote history file matches the one in the 
host history file (step 503), then the remote segment 
determines that two history files correspond to one 
another. Hence, the remote segment loads the remote 

10 history file into the remote workspace. 

In general, if matching history files do not exist 
on the remote and host computers, the remote segment 
transfers all remote database records to the host 
computer. Therefore, if the name of the host and remote 

15 history files match but the date and time stamps do not 
match (step 505) , then the remote segment assumes that 
remote history file is not the correct remote history 
file to be used. The remote segment removes that history 
file (step 506) and transfers all remote database records 

20 to the host computer (step 507) . If no remote history 
file matches the host history file (step 508), then the 
remote segment assumes an appropriate remote history file 
does not exist. The remote segment transfers all the 
records to the host computer (step 509). To transfer all 

25 the records in the above steps, the remote segment first 
loads and stores all records of the remote database in 
the remote workspace. The remote segment then transfers 
all records in the remote database to the host segment. 
If remote segment transfers all the records of the remote 

30 database to the host segment in either step 504 or 509, 
then the remote will go to step 528. It should be noted 
that the host segment will use the host history file, if 
one exists, to perform the synchronization. 

If an appropriate remote history file exists - 

35 i.e. conditions of steps 501 and 504 are satisfied - the 
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before comparing the data, with relatively -low risk 
inaccurate comparison. We have also use hash numbers as 
a unique identification code, which will be described in 
the second embodiment. 
5 The remote segment uses the remote history file to 

determine whether a record has been changed, deleted, or 
added since a previous synchronization. Therefore, for 
records that are unchanged, which typically constitute 
the majority of records in a database, the remote segment 

10 sends information that the host segment can use to 

identify the matching records in the host history file. 
That matching history file record contains the same data 
as necessary to use for synchronization as that on the 
remote database since the record is unchanged. 

15 Therefore, there is no need to send the whole record. In 
essence, the remote segment uses the remote history file 
to filter out information that is already contained in 
the host history file and sending only those records that 
have been changed or added. In some embodiments, the 

20 remote history file may contain all the field values of 
the records of the remote database. In those 
embodiments, the remote segment can determine not only 
which records have been changed but more specifically 
which field values have been changed. In that case, the 

25 remote segment can determine and then send only those 
field values that have been changed, further increasing 
the efficiency of using the slow data transfer link. 

We will now describe this process in detail. In 
the described embodiment, for each record of the remote 

30 database (step 515), the remote segment loads the field 
values, including the unique ID, of the record into the 
remote workspace (step 512). As the records are loaded, 
they are translated (e.g. "translated" as described in 
the '390 patent) into a universal format for the remote 

35 workspace. The records will be translated back into the 
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marks the record as unacknowledged (step 521) , the 
purpose and function of which we will now briefly 
describe and is also described in the '490, '926 and '645 
applications. 

5 Generally, the remote segment does not change an 

entry in the remote history file, until it receives an 
instruction indicating that the host segment has 
synchronized and updated the host database with that 
record. This is done so that if for any reason (e.g. 

10 user does not want to update that record of the host 
database as described above) the host database is not 
synchronized with that record, the remote segment will 
not treat that record as unchanged during the next 
synchronization. The acknowledgement may take the form 

15 of an "acknowledgment" flag or an "action" instruction 
which instructs the remote segment to add, update, or 
delete that record of the remote database, as described 
above. Therefore, for each changed and deleted record, 
the remote segment creates a new entry and marks the 

20 entry as "unacknowledged". If an "acknowledgment" flag 
is received, the old history file record is deleted. If 
an "acknowledgement" flag is not received, the new 
workspace entry is deleted. The steps will be described 
further below. 

25 If in step 515 the remote segment determines that 

the unique ID of the loaded record does not match any of 
the unique IDs stored in the records of the history file 
(step 521) , the remote segment assumes that the record 
loaded from the remote database has been newly added. 

30 Therefore, the remote segment sends the host segment a 
copy of the field values of those fields of the record to 
be synchronized (which may be all or less than all the 
fields) together with an "added* flag (step 524). . As in 
the case of a changed record, the remote segment creates 

35 a new remote workspace entry and enters the unique ID and 
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In order to synchronize the remote database with 
the host database, the Synchronizer transforms 
information from the remote segment into regarding 
unchanged records into equivalent regular database 
5 records. These transformed records are then used by the 
Synchronizer in the synchronization. Essentially, the 
synchronizer transforms and uses the information sent by 
the remote segment to identify a record in the history 
file that is a copy of the field values of the unchanged 

10 remote database record. In the described embodiment, the 
synchronizer also copies that history file record and 
flags as being the remote database record. 

The described embodiment uses the host history 
file to perform this transformation. At the beginning of 

15 a first synchronization between the two databases, all 
records in the remote database are loaded into the host 
history file. As changes, additions, and deletions are 
made to the remote database, during each subsequent 
synchronization, the same changes, additions, and 

20 deletions are made to the host history file. Therefore, 
the host history file at the end of each synchronization 
will contain a copy of the relevant content of the remote 
database after synchronization. By relevant, we mean 
data in the fields that are synchronized. For example, 

25 it may be the case that the host history file contain 
data in fields that are not synchronized. Moreover, if 
the records of the remote are mapped or recast into 
another format (e.g. "translated" as described in the 
'390 patent) the records of the history file contain a 

30 copy of the records of the database, as mapped, 

translated, or both. The Synchronizer uses the mapped or 
translated records for synchronization. Therefore, it 
only needs the mapped or translated copy of the unchanged 
record. In other embodiments, the host history file may 

35 contains copies of all the records exactly as they are in 
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As previously described, after the synchronizer 
has performed CAAR, the user must confirm to proceed with 
updating the remote database (step 406 in Fig. 11) . If 
the user decides to terminate the synchronization, 
5 changes are not made to the host history file or the 
databases. In the case of the remote database, as 
described in reference to Fig. 12, the remote segment is 
waiting for the synchronizer to finish synchronizing. If 
the user aborts synchronization (step 533) , the remote 

10 segment discards the remote workspace (step 534), saves 
the original history file without any changes (step 535) , 
and terminates the process at the remote computer. 

If the user confirms to proceed with updating the 
database (step 406 in Fig. 11) , control module 2 

15 instructs the synchronizer and the remote segment to 
proceed with unloading the records from the workspace 
into the remote database. As stated, at this point, the 
remote segment is waiting for the synchronizer to finish 
synchronizing (step 532 in Fig. 12). During the 

20 synchronization, the synchronizer has determined what 
"actions" with respect to which record in which database 
should be taken (update, delete, or add) to complete 
synchronization. If changes or additions are made to the 
host database in the case of particular record but no 

25 action need be taken with respect to that record in the 
remote database, the synchronizer determines that an 
"acknowledgement" should be sent to the remote segment. 
The synchronizer sends all the actions concerning the 
remote database together with the associated record to 

30 the remote (step 616) . The synchronizer then sends the 
unique ID of those records that require 

"acknowledgements" to be sent to the remote together with 
an appropriate flag (step 617). 

Referring again to Fig. 12, for each action item 
35 or acknowledgement received at the remote segment (step 
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history file to end the synchronization of the two 
databases . 

In the first embodiment, which we described above, 
the remote database assigns unique IDs to its records, 
5 We will now describe a second embodiment for the case 
where the remote database does not assign unique IDs to 
its records. In such a case, the remote segment provides 
some information less than all the fields of the records 
to uniquely identify an unchanged record to the host 

10 segment; This information may be a hash value. The host 
segment uses this information to find and then use the 
host history file copy of the unchanged remote database 
record to synchronize the two databases. 

To identify a record from the previous 

15 synchronization or an unchanged record, the remote 
segment can use a content based code, that is a code 
whose value depends on the content of all or a selected 
number of the fields of a record. In the second 
embodiment, the remote segment uses hash numbers. Since 

20 in the case of an unchanged record, its content has 

remained the same, its hash number remains the same. The 
hash number acts as a unique identifier and therefore 
enables the remote and host segments to identify the 
unchanged record by its hash code. The hash code can be 

25 used to identify a record that is stored in the host 

history file, since its content remains the same from the 
end of one synchronization to the time it is updated, it 
may also be transmitted to identify an unchanged record 
or an unchanged version of a changed record. A host 

30 history file record can in effect be identified using the 
hash code of that record. 

We will describe the operation of this embodiment 
in reference to Figs. 14 and 15. Steps 701 -711 are the 
same as steps 501-511 in Fig. 12, described above in 

35 reference to the first embodiment. These steps are 
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Therefore, the remote segment sends the host segment a 
copy of the field values of the record, the remote 
workspace index number, and an "added" flag (step 720). 
The remote workspace index number makes it easier to 
5 perform future search of the remote workspace when data 
with respect to this record is received. As in the case 
of changed and added record in the first embodiment, the 
remote segment also creates a new remote workspace entry 
and enters hash number value of the record (step 718) . 

10 The new entry is marked as "unacknowledged" (step 719) . 
It should be noted that although the remote segment 
treats the record as a new record, the remote segment can 
not distinguish between an added and a changed record. 
Therefore, the synchronizer during synchronization does 

15 not treat it as a new record. Instead, the synchronizer 
compares the record to determine whether it matches with 
any of host history file record which would mean it is a 
changed record. 

After reading all the remote database records and 

20 processing them (step 722) , the remote segment removes 
from the remote workspace all entries that have hash 
numbers that are unmatched (step 723) . These entries 
represent records that have either been changed or 
deleted since the previous synchronization. 

25 After the remote segment has finished providing 

data to the host segment, the host segment synchronizes 
the two databases based on the input from the remote 
segment. The remote segment waits until the host segment 
finishes synchronizing and instructs the remote segment 

30 in step 409 in Fig. 11 to begin unloading into the remote 
database (step 724) • 

Referring to Fig. 15, as in the case of the first 
embodiment, the synchronizer on the host computer uses 
the information to identify those records in the host 

35 history file that correspond to the unchanged remote 
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The synchronizer sends all the actions concerning the 
remote database together with the associated record and 
remote workspace index to the remote (step 809) . The 
synchronizer then sends the remote workspace index of 
5 those records that require acknowledgements to be sent to 
the remote together with an appropriate flag (step 810) . 
Therefore, the remote workspace index is used to identify 
which records in the remote workspace should be 
"acknowledged" . 

10 Referring back to Fig. 14, steps 725-729 are the 

same as steps 533-537, which were described in reference 
to the first embodiment. For each action item or 
acknowledgement received at the remote segment (step 
730) , the following steps are performed. If the data 

15 received indicates an "acknowledgement" or "action" with 
respect to a record that was sent to the host segment 
flagged as "added" (step 731) , the remote segment marks 
the new workspace entry that was created in either step 
718 as acknowledged (step 732). It should be noted that 

20 the remote workspace index number is used to locate the 
remote workspace entry. Therefore, as previously 
described, this entry will be written into the history 
file; at the end of the process at the remote segment. 

If the received data indicates an action item that 

25 tells the remote segment to update, change, or add a 
remote database record (step 733), the remote segment 
performs that action with respect to the remote database. 
The remote segment also updates the remote workspace and 
marks the entry as "acknowledge" (step 735) . 

30 After all the records have been received, the 

remote segment discards all unacknowledged entries from 
the workspace, which were newly created entries which 
were not acknowledged. Therefore, in case of those added 
or changed records with the user decided not to update 

35 the host database with, the remote history file remains 
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What is claimed is: 

1. A computer implemented method of 
synchronizing a first and a second database comprising: 

determining whether the records of the first 
5 database have been changed or added since the previous 
synchronization, based on data reflecting whether the 
records of the first database have been added or changed 
since a previous synchronization; 

if one of the records of the first database has 
10 not been changed or added since the previous 

synchronization, performing a synchronization with 
records of the second database using a record 
representative of the one record at the time of a 
previous synchronization, the representative record being 
15 stored in a history file containing records reflecting 
the contents of records of the databases at the time of a 
previous synchronization, 

2. The computer implemented method of claim 1, 
wherein the data comprises database generated data for 

20 keeping track of whether the records of the first 
database have been added or changed since a previous 
synchronization . 

3. The computer implemented method of claim 2 
wherein the computer generated data indicates the most 

25 recent date and time of when the records were created or 
changed. 

4. The computer implemented method of claim 2 
wherein the computer generated data comprises a flag set 
when the records are created or changed. 
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8. The computer implemented method of claim 2 
further comprising: 

modifying, adding, or deleting the records of the 
first database based on a result of the synchronization. 



5 9. The computer implemented method of claim 2 

further comprising modifying, adding, or deleting records 
in the history file using results of the synchronization 
such that the history file contains records reflecting 
the contents of records of the databases after the 
10 synchronization . 



10. A computer program, resident on a computer 
readable medium, for synchronizing a first and a second 
database, comprising instructions for: 

determining whether the records of the first 

15 database have been changed or added since the previous 
synchronization, based on data reflecting whether the 
records of the first database have been added or changed 
since a previous synchronization; 

if one of the records of the first database has 

20 not been changed or added since the previous 

synchronization, performing a synchronization with 
records of the second database using a record 
representative of the one record at the time of a 
previous synchronization, the representative record being 

25 stored in a history file containing records reflecting 
the contents of records of the databases at the time of a 
previous synchronization. 



11. The computer program of claim 10, wherein the 
data comprises database generated data for keeping track 
30 of whether the records of the first database have been 
added or changed since a previous synchronization. 
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16. The computer program of claim 11 wherein the 
first database assigns a unique identification data to 
the records of the first database, the computer program 
further comprising instructions for: 

5 performing a comparison of the records of the 

history file and the unique identification data of 
records in the first database that have been changed or 
added since the previous synchronization; and 

completing synchronization using a result of the 
10 comparison. 

17. The computer program of claim 11 further 
comprising instructions for: 

modifying, adding, or deleting records of the 
first database based on a result of the synchronization. 

15 18. The computer program of claim 11 further 

comprising instructions for modifying, adding, or 
deleting records in the history file using results of the 
synchronization such that the history file contains 
records reflecting the contents of records of the 

20 databases after the synchronization. 
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20. A computer program, resident orv a computer 
readable medium for synchronizing a first database 
located on a first computer and a second database located 
on a second computer, comprising instructions for: 
5 determining whether a record of the first database 

has been changed or added since a previous 
synchronization; - 

if the record of the first database-has not been 
changed or added since the previous synchronization, 

10 sending from the first computer to the second computer 
information which the second computer uses to identify 
the record of the first database to be unchanged, wherein 
a history file located on the second computer contains 
records reflecting the content of records of the first 

15 database at the completion of a previous synchronization 
and said information identifies a record in the history 
file reflecting the content of the record of the first 
database; and 

synchronizing the first database and the second 

20 database using the sent information. 
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24. The computer implemented method of claim 23 
wherein the second history file stores information in 
relation to the representative records and wherein the 
one of the representative records in the second history 

5 file can be identified from the stored information. 

25. The computer implemented method of claim 24 
wherein the information sent from the first computer to 
the second computer comprises information that matches 
the information stored in relation to the one of the 

10 representative records in the second history files. 

26. The computer implemented method of claim 21 
wherein the information comprises information identifying 
records other than the unchanged record. 

27. The computer implemented method of claim 21 
15 wherein the information comprises information identifying 

the unchanged record. 

28. The computer implemented method of claim 21 
wherein the information comprises information identifying 
the deleted records. 

20 29. The computer implemented method of claim 21 

wherein the information comprise information identifying 
the added records. 

30. The computer implemented method of claim 21 
wherein the information comprises a code, the code being 
25 based on at least a portion of the content of the record 
of the first database. 
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36. A computer implemented method of identifying 
a record of a database stored on a first computer to a 
second computer comprising: 

reading a record of the database; 
5 assigning a code to the record of the database, 

the code being based on at least a portion of the content 
of the record of the first database; 

transmitting the code to the second computer to 
identify the record to the second computer. 

10 37. The computer implemented method of claim 36 

wherein the code comprises a hash number computed based 
on at least a portion of the content of the record of the 
first database. 



38. A computer program, resident on a computer 
15 readable medium for synchronizing a first database 

located on a first computer and a second database located 
on a second computer, comprising instructions for: 

determining, at the first computer, whether a 
record of the first database has been changed or added 
20 since a previous synchronization, using a first history 
file located on the first computer comprising records 
representative of records of the first database at the 
completion of the previous synchronization; 

if the record of the first database has not been 
25 changed or added since the previous synchronization, 
sending from the first computer to the second computer 
information which the second computer uses to identify 
the record of the first database to be unchanged. 
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45. The computer program of claim 3€ wherein the 
information comprises information identifying the deleted 
records . 

46. The computer program of claim 38 wherein the 
5 information comprise information identifying the added 

records . 

47. The computer program of claim 38 wherein the 
information comprises a code, the code being based on at 
least a portion of the content of the record of the first 

10 database. 

48. The computer program of claim 47 wherein the 
code comprises a hash number computed based on at least a 
portion of the content of the record of the first 
database. 

15 49. The computer program of claim 47 wherein the 

information further comprises a first plurality of 
records of the first database identified as "changed or 
added", the program further comprising instructions for 
using said information to indentify a plurality of the 

20 first database as "deleted or changed" since a previous 
synchronization. 

50. The computer program of claim 38 wherein the 
information comprises a code uniquely identifying the 
record of the first database. 

25 51. The computer program of claim 50 wherein the 

unique identification code is assigned by the first 
database to the record of the first database. 
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55. A computer implemented method of 
synchronizing at least a first and a second database, 
wherein the first database provides information regarding 
records which have been added, deleted or modified since 
5 a previous synchronization, the method comprising: 

storing in a history file records representative 
of the records of the first database after the previous 
synchronization; 

obtaining information regarding the records which 
10 have been modified, deleted, or added since the previous 
sy nchr on i z a t i on ; 

performing a first comparison of the records of 
the second database with records in history file 
corresponding to records of the first database that have 
15 not been modified, added, or deleted; 

completing the current synchronization based on 
the outcome of the first comparison and the information; 
and 

modifying, adding, or deleting records in the 
20 history file using the information obtained from the 
first database such that the history file contains 
records representative of the records of the first 
database after the current synchronization. 
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